will help readability if we do something like this

type QValueArr []qvalue.QValue

I disagree, moving [] to the end as Arr adds little & requires wrapping the type while passing it around, when we just want []qvalue.QValue anyways

I did consider putting type QRecord []qvalue.QValue in model, but seems like it obfuscates the truth. I'm generally annoyed when I'm using a library & it turns out they've wrapped []T into some other type. I'd go as far as to say I'd prefer a type QRecord struct { Values []qvalue.QValue } over a type alias when it comes to wrapping slice types

For me it's that double slices read weird, and having an alias for that would help. Fair point on requiring type wrapping though, would a type alias work better? https://stackoverflow.com/questions/61247864/what-is-the-difference-between-type-alias-and-type-definition-in-go

Approving anyway as this is primarily a stylistic difference.

Type alias is type wrapping, it's specifically what I want to avoid since it makes a type that you can use slice operators on without being an explicit slice type, so you'll end up casting it to slice when you want to do other things like call functions from slices on it

Double slice is indeed awkward, but it let's someone know they should get used to dealing with nested slices since signature or not that's what they're dealing with